Flow drops/v4#8949
Conversation
Now that flow drop is applied to packets before other processing, no drop has to be issued on a packet.
Remove logic to apply flow drop, as this is now handled in the flow engine. However, keep the logic that frees/cleans the session state.
When a flow is in the drop flow state, don't use pseudo packets when it is timing out. There should be no work left to do at this point.
Test broke after recent changes. Functionality is tested in suricata-verify, so just remove the test.
|
Information: QA ran without warnings. Pipeline 14178 |
jufajardini
left a comment
jufajardini
left a comment
There was a problem hiding this comment.
I like that we're handling the drop when updating the flow packet state, and that we're checking for the drop before updating app-layer for UDP protos. Seems like the drop handling is more contained. I saw that we are not calling 'FlowSetNoPacketInspectionFlag' and 'DecodeSetNoPacketInspectionFlag' after checking for the flow drops. Is that because we are handling the dropped flow earlier?
First of the commits seems to have a typo: "apply flow do" -> I imagine that should be "flow drop"?
Yeah, the detect engine checks for |
|
Merged in #8951 |
3 participants
SV_BRANCH=pr/1224
https://redmine.openinfosecfoundation.org/issues/5802